8.1 Development testing
 8.2 Test-driven development 
8.3 Release testing 
8.4 User testing

Chapter 8 Software Testing
■ Validation: Are we building the right product? 
■ Verification: Are we building the product right?

Meet stated functional and non-functional requirements
Validation: determine that the product being built is the desired product
Verification: determining that it works the way we expect
Software purpose determines HOW important V and V are
	Critical need means reliability greater etc
Cheap system, customers can be more forgiving
	More willing to do workarounds
Marketing environment:
	Competitors
	Price
	Schedule
Inspections
	Your partner may be able to see errors
	Even if your partner is a dog
	Incomplete work can be inspected
	Quality of programming shows on inspection
	Some errors can cover other errors
	Cannot replace testing 
Testing
	Automatic test data generation is rarely possible
	Humans need to create test data
	Usually need to specify results
	Running test data can be automated

8.1 development testing
	Done by programmers
	(maybe in pairs)
	Unit, component, system
	Unit:
		Test each part
		Call with different parameters
			(including incorrect ones)
		Use driver
		Check results
		Might use mock objects to test
		Generalization makes test more difficult
		Choose test cases
			Normal
			Problem
			Illegal
			Overload or oversize
		Partition testing
			Groups of values
			Check boundaries

Component:
	To initially test the component, do you need the units?
	Use stubs
	Parameters
	Shared memory
	Procedural testing
	Message testing
	Interaction between faults
	Interface mis-use
	Interface mis-understanding
	Timing errors
System testing:
	Look for misunderstandings
	Case based testing
	Check all menu options
	All combinations of functions
	Both correct and incorrect input
	Complexity
		(footnote in multi-column format)

Test driven development:
	Incrementally add test data
	Test until working
	Add more data, repeat
	Polish until working well for existing data
	THEN add new functionality or more text data
	If it crashes, you know what it crashed on!
	Run prior test cases each time, automatically

Release testing
	Development team should NOT do release testing
	Purpose is to make sure it is good enough to use
	(fits user requirements)

Requirements based testing
Scenario testing
Performance testing
	Fast? Accurate? 

User testing
	Alpha testing (internal)
	Beta testing (open to users)
	Acceptance (can be conditional)

More pragmatic ideas:
	Put a print statement in every condition
		Know if executed
	Put in checks for illegal values
		0, negative, non-numeric
	Simulate all possible decisions

Inspections and your dog
	
Test data
	Sample normal values
	Illegal, odd, extreme values
	Overload
Generate all possible error messages
	Check negative, 0
	Cause all buffers to overflow
	Underflow, overflow, etc.
	Force invalid outputs
	Values too large or too small
	Test null pointers
	Cause components to fail
	Stress testing
	Vary order of components